1. Field of the Invention
This invention relates in general to systems and methods for transmitting compressed data streams, and in particular, to a system and method for pacing the transmission of compressed blocks of data from a server to a receiver that minimizes the size of the buffer required at the receiver.
2. Description of The Related Art
Recent advances in digital video and audio compression technology have created a marriage between television and personal computers. For example, it will soon be possible for a television viewer to watch a favorite video by simply downloading it to his TV through a telephone line.
Compressing the data stream that makes up such a video before sending it is desirable for two principle reasons. First, the data stream representing the video would take too long to transmit in the uncompressed state. Second, the uncompressed data stream would take up too much memory.
Different types of compression technology are currently used. However, two technology standards, MPEG and JPEG, each with its own variations, have evolved for compressing data depicting still pictures (images) and moving pictures (video), respectively.
With still image compression, transmission by a server and decompression by a receiver only has to be fast enough so that a viewer does not get bored waiting for an image to appear. But when transmitting video, a high enough frame rate has to be accomplished to produce satisfactorily smooth motion. North American television viewers are used to a rate of 30 frames per second, which means the receiver must access, decompress, and display a new image every 30-40 milliseconds. At any slower rate, the motion will seem slow or jerky.
Video compression can drastically reduce the data rate required to transmit an otherwise uncompressed data stream. For example, when a server transmits a video of a talking face, the only data that needs to be transmitted from one frame to the next is the data showing the motion of the lips, and any other features that may be moving. Therefore, after the receiver has displayed the first scene using the data for one frame, the server can represent the subsequent frames using very little data. On the other hand, when there is a sudden scene change in the video, the server needs to send the entire background without compression. If it takes too long for this data to reach the receiver, the video will not display smoothly. To adjust for these fluctuations in data transmission, receivers typically use large buffers that can store enough data before the time it is to be displayed.
Although there are several environments currently used to transmit compressed video and audio data, the environment widely recognized as being preferable is an asynchronous transfer mode (ATM) network. ATM networks transmit an encoded data stream in short, fixed-size cells of information using statistical multiplexing. According to current standards, these cells each carry only 384 bits of data. Further, the cells arrive in the same sequence in which they were transmitted. One characteristic of ATM networks is that they guarantee delivery of transmitted data at a requested bandwidth within a highly predictable delay period.
Guaranteed delivery networks such as ATM have been used to transmit video data streams compressed into blocks of data. Depending on the video compression technology used, including variations of MPEG and JPEG, each block transmitted can contain the data for displaying one frame or a small multiple of frames of video. Thus, each block can represent a constant duration of display time regardless of its length in bytes.
Although data blocks are consumed at a constant rate in blocks/second at a receiver in a guaranteed delivery network such as ATM, some blocks take longer to transmit than others because they contain more bytes. The constant rate transmission of such networks means that the amount of time it takes blocks to reach the receiver is proportional to how large they are.
Currently, transmitting condensed video or audio data over guaranteed delivery networks like ATM presents two problems. The first problem is guaranteeing continuous delivery of information for uninterrupted display of video. The second problem is determining what size buffer to use at the receiver.
Without continuous delivery, a person watching a video being transmitted will notice "outage," a momentary lack of picture or frozen frame, and "overlay," a loss of picture data when data is sent faster than it can be displayed.
A prior solution to preventing outage and overlay has been the use of a feedback loop between the receiver and server to ensure that the receiver does not run out of data or the transmitter send too much data. However, such feedback systems can be cumbersome and increase complexity of data transmission.
Another solution to preventing outage has been to use prioritizing algorithms that separate compressed video data into a high priority "base layer" and a low priority "enhancement layer." The base layer is sent first to the receiver so that it can reconstruct a minimally acceptable image. It is followed by the low priority enhancement layer, which enhances the minimally acceptable image. If congestion develops, for example because the selected bandwidth is too low or because too much data is being transmitted at one time, the data for the low priority enhancement layer is discarded. In this way, the receiver can continue to display at least a minimally acceptable image. An example of such a system for ensuring continuous image display is provided by U.S. Pat. No. 5,515,377, issued to Horne et al., and assigned to AT&T. Although prioritizing data into low and high priority categories can help avoid total loss of video, it is disadvantageous because it inherently accepts a loss of video quality.
The second problem in transmitting compressed video is determining how much buffer space is needed at the receiver to avoid outage. The required buffer size depends on the quality of picture transmitted, but may range from 1.5 to 15 Megabytes. The cost of providing memory for such buffer space in receivers can be significant, especially when the receiver is not a general purpose computer with existing memory, but a set-top box built solely for decompressing and displaying compressed video.